A computer program generally consists of at least three components: a user interface; an application program; and memory or storage. Early computers used tape or card readers and printers for primary user interface. The program or application was loaded to run on the central processing unit and either memory or disc storage or both provided data storage. As the industry matured, computers were able to interact with terminals to provide another important user interface. Small computers, known as workstations, became available to provide a user interface and computing power in the same unit. With the advent of personal computers or PCs, inexpensive computers have replaced simple terminals in many computer installations.
In early computers, a program could reside only in a single computer. Large programs could be broken into segments which could be loaded, as needed, into active memory in the central processing unit. As computers became more powerful, larger programs could be run but the capacity of a single computer remained a fundamental limit for the size of a computer program.
As workstations and PCs became more prevalent, a paradigm evolved which attempted to maximize efficiency by using available processing power in a logical manner. Since many users were interfacing with larger computers through a workstation or a PC, programmers realized that functions required to operate the user interface, such as screen redrawing, video refresh, graphics generation, windowing control (size, position and overlap), and input processing (character and function key handling, interrupts, and such), logically should be handled by software which was resident on the local workstation. Following this same line of reasoning, many programs require extensive access to computer storage. A classic program of this type is a database where a series of records are stored in a special storage area. One database used by many industries is an inventory record. Another database might be for payroll or for accounts payable. Generally, a modern database is composed of a number of records stored in the systems storage area. Multiple users can use the database simultaneously, but there must be provisions to prevent two users from accessing the same record at the same time for then both would be updating old information and possibly making and storing inconsistent changes. Programmers developed server functions which controlled record access for reading or writing information, record locking and, when available memory or storage was limited, specifying media changes such as mounting or unmounting interchangeable media such as discs or tape.
Manipulating graphic information such as windows or menu selection, graphic objects and such generally requires transferring large amounts of information, especially when manipulating bitmaps. If this information must be passed over a common network shared among many computers, then the network can easily be filled with traffic moving graphic images. In a similar way, the low level commands required to select a specific storage media, move the reading heads to the correct portion of the media and pull the information from the media requires a fair amount of activity between the controller and the reading heads when all the user or program really needs is the result, typically some or all of the contents of the requested record.
This paradigm has evolved to be known as a client-server. The server, in general, provides control of and access to one or more shared resources. One useful server is a database server, discussed above. Another useful server is a file server, where the server has access to program or data or other files and can access this information upon request. A print server might store and direct print jobs to a collection of printers which are then accessible to a large number of users through simple calls to this server.
The Evolution of Client-Server
Client-server has grown rapidly with advances in database management system (DBMS) technology and particularly relational database management system (RDBMS) technology. The architectures of the leading multi-user RDBMSs provide a separation between the user-specific work of the application program and the shared data management services of the RDBMS engine. This architecture allows a single RDBMS engine to service multiple applications as well as multiple users of the same application. Structured query language (SQL) provides applications with an easy way of requesting RDBMS services while shielding applications from the details of data management (e.g., concurrency control, backup and recovery, data access strategies).
With the advent of RDBMS networking products, applications could be off loaded from the host and placed on a different machine, using SQL as the protocol to communicate between them. At first, this technology was used between two multi-tasking minicomputers, one that ran the RDBMS engine (the back end) and the other (the front end) that drove the users' dumb terminals. With the growing acceptance of the PC, it was a logical step to replace a multi-tasking front end machine with a collection of PCs, each of which ran its own copy of the front end application program. The growing popularity of the graphical user interface (GUI) has further solidified the appropriateness of client-server, since inexpensive desktop computing cycles can be used to drive the many details of the GUI.
Meanwhile, on the RDBMS server side, the technology has also advanced. RDBMS vendors now offer multi-threaded servers with improved performance and reliability. Some offer stored procedures that can speed the processing of predefined SQL queries. Many also offer gateways to translate the RDBMS vendor's SQL dialect into RDBMSs and file systems from other vendors.
Today, client-server has come to mean PCs running an application program that accesses a shared RDBMS server over a network. Client-server is gaining rapid acceptance among Fortune 1000 companies where is being used today for departmental decision support applications. These companies are very interested in extending the client-server paradigm to enterprise-wide online applications.
Monolithic Client Application Programs
Most client-server developers today accept a predefined division of computing functions between clients and servers. Referring to FIGS. 1A and 1B, with the most commonly used predefined split, clients run the application program which handles the user's display and any application processing of the data that goes into or comes out of the RDBMS. The application program passes SQL to the RDBMS interface (which also runs on the client). The RDBMS interface then ships the SQL across the network to the RDBMS server which processes the request and returns the requested data or a status message back through the RDBMS interface to the application program. According to this model, the application program is monolithic and resides entirely on the client. It is a client application program. This model is sometimes called remote data management because the database is separate from the application program. Other models for splitting functionality between clients and servers are discussed below.
There are many high level tools on the market today for building client application programs. These tools typically include a screen designer and a high level language, often called a 4GL (Fourth Generation Language), for defining application functionality. Most of these tools support rapid prototyping or the ability to build an application as an interactive process of creating a quick prototype and subsequently refining it.
Monolithic client application programs may be well suited for decision support involving a single RDBMS. Running the entire application on the client, however, may present a number of problems for more complicated applications. These problems include:
inadequate processing power on the desktop to drive the entirety of a complex application program PA1 slow performance due to excessive network traffic PA1 difficulty of interfacing with data sources other than the primary RDBMS and those supported by the RDBMS vendor's gateways PA1 minimal reusability of application components among multiple applications PA1 As client-server evolves from a departmental to an enterprise-wide strategy, application partitioning will be a key strategy. PA1 Application partitioning is the ability to create a unified application and subsequently break it into a set of modules that execute on different nodes in a networked environment. PA1 Application partitioning can be an important strategy for increasing performance, control, and flexibility. PA1 Partitioning leverages the client-server model to support a new generation of enterprise applications. PA1 Forte was designed as a tool for developing and deploying partitioned applications.
Cooperative Processing
Application partitioning is best understood in the larger context of cooperative processing (an umbrella term that describes the division of application functionality in a networked environment). It would be incorrect to assume that application partitioning is synonymous with cooperative processing. An understanding of the distinction between these terms can help to illustrate the concept of this invention. To make the distinction, it is first helpful to look at the different styles of cooperative processing as enumerated by the Gartner Group, a market research firm based in Stamford, Conn.
Gartner's classification of cooperative processing styles is based on an application model that includes three different computing functions-user presentation services, application logic, and data management. Listed below are four of the ways for dividing these functions between computers. Each represents a strategy for tackling different application problems, and each is supported by a different set of tools. Together they illustrate some of the alternatives that confront IS managers as they move from stand alone host-based environments to client-server environments.
Remote Data Management. This division of functions places the presentation services and application logic on the client, while the server performs the data management functions. The communication protocol between these components is SQL. See FIG. 2.
Remote data management is a very common model for mainstream database client-server applications where a set of users interact with a desktop application that accesses a shared relational database (RDBMS) sever. This model can operate with a character oriented user interface or a graphical user interface (GUI). Many tools are available today for building applications that utilize this model (e.g., SQL*Forms, Powerbuilder, Uniface, and other 4GLs).
Distributed Presentation. This model, often called "frontware" or "screen scraping," supports a division of functionality within the presentation portion of an application. Distributed presentation takes a traditional mainframe application driving 3270 screens and allows developers to add GUI-based presentation services that run on a PC desktop. See FIG. 3. The 3270 data stream serves as the communications protocol between machines.
Distributed presentation allows organizations to upgrade the user interface to an existing application without altering the application. Several products in the market today support this approach, and they are different products from those that support remote data management.
Distributed Data Management. This model supports a division of functionality within the data management portion of an application. With this model, data can reside on more than one computer, and a distributed data management product will coordinate access to the data wherever it may reside while preserving transparent application access. Referring to FIG. 4, the distributed database knows which tables are on each server and routes requests accordingly.
Distributed data management can be used in conjunction with remote data management where an application running on the client may access data that is distributed across more than one RDBMS server. A few of the RDBMS vendors offer distributed data management products. Applications accessing distributed data can be developed with traditional 4GL tools.
Distributed Function. This model supports application logic that resides on more than one machine. The communication mechanism may be a remote procedure call (RPC) or a more conversational communication mechanism (e.g., IBM's APPC or CPI-C). See FIG. 5.
In their report Client/Server and Cooperative Processing: A Guide for the Perplexed, 1991, Gartner Group observes: "The distributed function style is particularly powerful for complex applications that are both highly user-interactive and database I/O intensive . . . . Because the functions reside on the more relevant (local) node, the number of messages that must be sent over the network between A [the client] and B [the server] is minimal, thereby enabling relatively fast response times for complex workloads." Gartner also-observes: "Distributed function applications are inherently the most difficult cooperative processing applications to design and develop, since there are two separately compiled application programs. Developers must analyze thoroughly where each function should reside and what type of dialog must occur between the two programs."
Application partitioning, which is central to the method of this invention, is a technology that simplifies the development of applications using the distributed function model described above. The general client-server paradigm, discussed above, is based on a division of computing functions among two or more nodes in a network. By dividing up computing tasks, client-server supports a flexible and cost effective computing model that may displace traditional host-based computing as the dominant paradigm for the future. Application partitioning goes beyond traditional client-server technology and provides an approach for allocating application functionality among clients and servers.
The allocation of computing functions may present many options, each with implications for performance, control, and/or flexibility. To handle application partitioning effectively, one should consider several issues surrounding the allocation of functions across multiple platforms in the network. The overall goal is to promote more effective client-server applications that can solve emerging business problems.